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INTRODUCTION 





One of the most substantial tasks associated with EDP operations is that of converting 
an existing system to a new computer. Few other EDP tasks are as large or as complex, 
but few others are as important — for the benefits which you will derive from the UNIVAC 
9200 System will largely depend on how well the conversion from the old system has been 
carried out. 


For all its size and complexity, the conversion effort can be carried out with a minimum 
of difficulty if performed in a thorough, logical manner. To aid top management, data pro- 
cessing executives and other supervisory personnel of any organization making the tran- 
sition to the 9200 computer, Univac has prepared this manual, THE UNIVAC 9200 Installa- 
tion Planning Guide, which outlines simple, easy-to-use conversion methods. Their 
implementation is made easier by Univac-devised work charts which relate to each 

and every conversion step. Use of these forms will enable you to record and analyze per- 
tinent information during each of the five conversion phases described in separate chap- 
ters of this manual: 


Installation Scheduling and Control 
Documentation 

Application Development 
Programming 


Record Conversion 


Associated with the UNIVAC 9200 Installation Planning Guide is another 

Univac manual, the ‘‘9200/9300 Card Report Program Generator Reference Manual,’’ 
UP-4106. This manual describes the nature and use of the Report Program Generator 
language, a simple tool for the generation of programs for business applications. 
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I. Installation Scheduling And Control 


In preparing for the conversion to a new computer you must first establish a means of con- 
trolling the effort and the events that affect the conversion. The purpose of this controlis 
to permit you to determine the progress you are making. You can then make intelligent de- 
cisions as to what the future course of action should be. The establishment of a control 
plan encompasses many areas. You need to identify all the activities that must take place 
prior to installation. Next, you must determine the amount of work involved in each activ- 
ity or task. From this you can prepare a schedule of events that becomes the heart ofyour 
control plan. You can then compare your actual progress against the schedule and know 
where you stand. If you are not on schedule you can take whatever corrective action is 
required. This subject is covered in detail in Chapter I. 


Il. Documenting The Present System 


Documentation involves the systematic gathering of details of the present methods used 
in accomplishing the goals of the application and documenting them. This includes appli- 
cation flowcharts, card and printer layouts and program logic. The investigation and doc- 
umentation phase of conversion is fully detailed in Chapter II. 


Il. Application Development 


Application development is the process of preparing the application for programming on 
the 9200. This is the phase where the documentation of the present (old) system is re- 
quired. Using the details gathered during the Investigation phase you can develop the new 
system in an orderly manner. The old system documentation will point out what must be 
accomplished in the new design, details which might easily be overlooked will have been 
recorded in the preceding phase. In the Application Development phase you will prepare 
applications flowcharts and program logic charts for the new system. Application Develop- 
ment is discussed in detail in Chapter III of this manual. 


1V. Programming 


Programming of the applications is the final phase of the work required to convert to the 
9200. It covers everything from coding the programs through testing the programs, and 
finally, preparing the operator instructions necessary for their utilization. Chapter IV con- 
tains a discussion of this phase of conversion. 


V. Record Conversion & Planning The Final Cutover 


The advent of a new computer will undoubtedly cause some alteration in the output of the 
EDP department. To insure a smooth transfer of work from the existing system to the new 
system, a comprehensive and well documented plan must be developed and adhered to. In 
Chapter V Univac presents guidelines to assist you in developing your plan. Although 
general in nature, these are the most important to a successful installation. 
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l. INSTALLATION SCHEDULING 
AND CONTROL 


INTRODUCTION 


This first chapter of the UNIVAC 9200 Installation Planning Guide describes the methods and 
charts developed by Univac to help you establish proper conversion control as soon 

as the decision is taken to order a UNIVAC 9200. Through this control, you will always 

be able to quickly evaluate the progress and completeness of your conversion effort and 

to take prompt remedial action if the need arises. The task of establishing full conversion 
control involves five basic functions: 


Preparing the Applications Conversion Plan 
Establishing control over other conversion requirements 
Developing a master conversion control 

Monitoring conversion progress 

Planning the final cutover 


PREPARING THE APPLICATIONS CONVERSION PLAN 


Planning the conversion of present applications to the UNIVAC 9200 System requires 
answers to four questions: 


a What are the applications to be converted? 
mw How are they to be converted? 

@ How much work will it take to convert them? 
@ When will they be converted? 


The four functions which underlie preparation of this Plan, therefore, are: 


Inventory of present runs by application 
Selection of the conversion method 
Workload estimation 

Scheduling 


Inventory of Present Runs by Application 


The design of conversion control must naturally reflect the number of runs in each individ- 
ual application, such as payroll or accounts receivable, and the ease with which each run 
can be programmed. Preparation of the inventory will, therefore, require that the following 
information be prepared for each run: 


a Application identification 
@ Run listing and evaluation 


The Program Inventory List (see Figure I-1) will aid you in these two tasks. It provides a 
simple medium for systematic recording and analysis of all pertinent information. . 


Application identification 


Before filling out the Program Inventory List, you should group runs according to the ap- 
plications to which they apply. The name of each application should then be written a- 


cross the top of a separate List page. 


In some cases, there will be runs that are not directly related to any of the applications 
you have identified. These runs can be either: 


m gathered together in a miscellaneous 
category, or 
@ included with one or more other applications. 
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Run listing and evaluation ~~? 


Once applications have been identified, each calculation and each print run for each ap- 
plication should be listed in proper sequence on the appropriate page of the Program In- 
ventory List. It is important that only runs be listed, not programs or control panels, as 
multiple runs are often programmed on a single panel. Along with each run’s name, the 
following information should be listed: 


run number 

type of machine 
type of processing 
ease of programming 
priority of run 
frequency of run 


Run number should be the one presently used to identify it. If runs are not now numbered, 
numbers should be assigned in sequence for control purposes. It is recommended that num- 
bers be left unused within this sequence to accommodate possible. future additional runs. 


Type of machine indicates the equipment the run is now done on. The machine number 
should be shown (i.e., 403, 604, etc.). When two machines are used together in a run, 
their numbers should be indicated jointly (i.e., 407/519). 


Type of Processing entry is either (c) or (p) to show whether the run is for calculation or 
print. Some print runs should be considered to be calculating runs if they are used pri- 
marily to summarize data for punching, and either there is no printed output or the output 
is not required in the system. 
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Figure !-1. Program Inventory List 








Ease of programming of the run refers to the degree of difficulty known to have been ex- 
perienced in programming a given run for the machine it presently is on. If there are mul- 
tiple runs on one control panel, only the difficulty of the one run under consideration 
should be evaluated. Rating should be simple (S), average (A), or complex (C). 


Priority of the runs refers to the desirability of the run’s output being included in the new 
system. Methods for determination of this desirability are described in Chapter III. The 
following priorities should be assigned: 


(1) if required for the application 

(2) if desirable, but not absolutely necessary 
(3) not needed by delivery date 

(4) not needed 


Frequency of the run should be entered as: 


(D) daily (SM) semi-monthly 
(W) weekly (Q) quarterly 
(B) bi-weekly (SA) semi-annually 
(M) monthly (A) annually 


In the case of semi-annual and annual reports, the data on which the reports are run 
should be entered under comments. 


The Comments section of the Program Inventory List can be used for entry of any com- 
ments. for any particular run. The List also contains two columns, headed Documentation 
and Cross Reference. These columns will be used later in the Documentation and Appli- 
cations Conversion Planning phases of system conversion, described in Chapters II and III 
respectively. 


Selection of the Conversion Method 


Once all runs within each application have been listed and evaluated, a decision can be 
made as to the manner in which they will be transferred to the UNIVAC 9200. There are 
two approaches that can be followed. Both are fully described in Chapter II]. One approach 
is conversion of which there are two types — Straight Conversion and Consolidation. The 
other is System Design. However, the difficulty of new system design and the delays that 
it can cause are such that use of this method is recommended only for new applications 

or when a drastic reorganization of the existing system is required for greater efficiency. 


Straight Conversion 


This method calls for the conversion of each unit record equipment run to an equivalent 
run on the new system. It permits a prompt conversion within a tight time schedule. How- 
ever, it tends to result in a greater number of runs than do other methods. This is parti+ 
cularly true for applications involving a large number of calculating runs. 


Consolidation 


The method involves the combining of several unit record runs into a single 9200 run. 
This merge is particularly effective in reducing the need for separate calculation runs by 
marrying them with their associated print runs. Another advantage of consolidation is that 
it will usually produce a more efficient system than that which was previously in force. 
Less operator and machine time will be required and card costs will often be reduced as 
the need for punched card storage of intermediate results is eliminated. 























New System Design 


Complete redesign of application procedures for the new system is the most difficult and 
time-consuming method but, in some cases, it yields outstanding results. All application 
requirements must be analyzed to determine the best method to satisfy them using the 
new system. This analysis must include the source documents, the management reports, 
other working reports, necessary processing, history requirements, paper flow both within 
and outside the data processing department, and all other areas affected by the applica- 
tion. After a particular conversion method has been chosen for a given application, it 
should be entered at the top of the page of the Program Inventory List. 


Workload Estimation 


Following the completion of the inventory of applications to be converted and the deter- 
mination of how they should be converted, you must estimate how much work should be 
spent on each conversion task. Each application must be analyzed to indicate the scope 
of each of the three major operations described in Chapters II, III, and IV respectively 
required for its conversion: 


a Documentation 
a Application development 
a Programming 


The workload for the application can then be estimated, using the pertinent Program In- 
ventory List Information. There are many factors involved in estimating the conversion 
workload. Some apply only to your organization. Others are more common, and have been 
the subject of extensive study by the Univac systems staff. A Univac systems analyst 
will assist you in estimating the work required for each task. He will provide suitable 
work forms and will possess the experience required for accurate evaluation of the total 
workload and precise determination of how it should be distributed. 


Estimating the conversion workload requires the following information: 


a The Program Inventory List 

a Conversion method selected for each application 
mw Documentation status of the present system 

m Manpower availability 


Documentation Status of the Present System 


This determination involves two factors: the amount of documentation such as flow- 
charts and manuals now available, and the knowledge which exists concerning present 
system programming. 


Any available documentation should be reviewed to make certain that it is complete and 
up to date. The extent of present system programming knowledge can be evaluated through 
two questions. Are the people who programmed the system still present and do they re- 
member the programs’ logic? Could the present system be reprogrammed without any out- 
side assistance? 


Manpower Availability 


This must be estimated in order to determine the number of man days that can be allo- 
cated to each conversion task. Man days represent time that staff members will be able 
to spend on conversion work between the end of the planning stage and delivery of the 
new system. Many separate factors, such as cyclical workloads, vacations, training, etc. 
must be considered in determining personnel availability. Also to be considered are the 














secondary effects of other personnel being absent for any reason. A calendar should be 
used when personnel availability is being computed. The workload estimating process 
furnishes two important items of information. The first is the time which each conversion 
task should take if it is to be accomplished before total conversion delivery. The second 
is the approximate number of man-hours per day required daily for conversion work. This 
information will underlie subsequent conversion scheduling. 


Scheduling 


After the conversion tasks have been defined in terms of scope and time requirements, 
the order in which they are to be done should be determined. Several factors affect 
scheduling. For instance, the next conversion phase will be Application Documentation, 
and it is recommended that the first application to be documented be the easiest and 
shortest (the same recommendation applies to Programming). An easy, gradual introduc- 
tion to documentation procedures may thus be had. Similarly, the entire system should be 
documented before the start of the Application Conversion Planning phase. Documenta- 
tion for all applications must be available so that their interrelationships may be ex- 
amined. 


Each major conversion phase should be completed before the next one begins. This al- 
lows a more orderly employee training period. Finally, as the interrelationships between 
all applications become apparent, the new system can often be simplified. In this way, 
you can avoid subsequent reprogramming work to eliminate inefficiencies that should have 
been remedied during conversion. 


The Workload Scheduling Chart 


This chart (see Figure I-2) has been designed by Univac to permit a graphic representa- 
tion of the schedule. Use of the chart will enable you to control the progress of conver- 
sion and to spot any developing conditions that require corrective action. 


The chart is divided into two portions: for written information and for graphic representa- 
tion. To fill in the first portion, you should: 


(1) Indicate the application in the Application column. 

(2) In the Task column, list all tasks in the sequence in which they will be converted. 

(3) Fill in the name of the person responsible for conversion of this task in the Per- 
sonnel column. 

(4) Fill in the number of man-days required to complete each task in the Required 
Days column. 

(5) In the Start Date and End Date columns, show the starting and completion dates 
for each task. This should be done using a calendar after all tasks have been 
listed. These dates must reflect the availability of the person assigned to the 
task. : . 


To fill out the graphic portion of the chart: 


(1) Fill each of the top row Date boxes with dates for Fridays two weeks apart. 

(2) Draw a horizontal bar through the ESTIM. (for ‘‘estimated’’) row extending through 
the time period allocated for completion of the task. 

(3) As tasks are being completed, draw a horizontal bar every two weeks through the 
ACTUAL row to indicate the actual time that work in progress for this task is 
taking. 

(4) As tasks are completed, the completion date should be inserted in the Date of 
Completion column. 
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anes Figure 1-2. Workload Scheduling Chart 














At the bottom of the Chart is a bar graph labelled ‘‘Estimated Days Completed.’’ This 
graph should be scaled to represent manpower availability as a man-day total. As each 
task is completed, the number of estimated man-days assigned to the task should be 
marked off on the bar graph. This will show how much of the total conversion work has 
been completed to date, and how much remains to be done. 


Program Check List 


Besides the Program Inventory List and the Workload Scheduling Chart a third control 
form, the Program Check List,has been provided. This form (see Figure I-3) will be used 
in the application, conversion, and programming phases. Its purpose is to provide a means 
of controlling the work done on each of the programs for the 9200 System. 


During the application planning phase, the runs to be programmed for the 9200 will be de- 
termined. The following information should be transferred from the Program Inventory List 
to the Program Check List (see page 2 of this chapter): 


(1) Run name and number 
(2) Run priority 
(3) Numbers for runs being replaced (to be entered in Cross Reference column). 


In assigning priorities, it is recommended that the following designations be made: 


a "1" — required by delivery date 
a "2" — desired by delivery date 
gm "3" — not needed by delivery date 


As the application planning phase progresses, input, output and logic documentation are 
prepared for the new program. These runs will be reflected in the proper column for that 
program. 


When the programming phase is begun for each application, the proper program check list 
should be updated. In this way, control can be maintained over the progress of each of 
the several programs being worked on at this time. 


OTHER CONTROL REQUIREMENTS 


Conversion of applications to the Univac 9200 is not the only area that requires thorough 
planning and control. There are many related installation support tasks that must be done 
before system installation if it is to go promptly on the air. These tasks include: 


m Site preparation 

m Education of personnel 

w New supplies 

m Cancellation of present equipment . 
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Figure |—3. Program Check List 














Site Preparation 


The most efficient installation layout should be determined, and plans should be made to 
install new equipment in its final location so that it will not have to be moved. This is a 
very important planning step, and one in which you will receive the same Univac support 
as in all other installation phases. Your Univac sales representative will assist you in 
making an early inspection of your site. He will give you all information necessary to pro- 
perly prepare for the physical installation of the 9200. This work should be completed 
well before delivery so that any deficiencies in the modifications can be eliminated. 


Education of Personnel 


As soon as systems planning is completed all members of your organization should be in- 
structed in the new system’s nature, requirements and use. Instruction to be planned and 
scheduled ranges from operator training and programming courses to executive seminars 
for management. Instructions should be written to cover every processing step and, if pos- 
sible, practice runs should be held. With the entire organization thoroughly aware of the 
UNIVAC 9200 System, the Data Processing Department will enjoy maximum efficiency. 


New Supplies 


Forms, forms control tapes and new card layouts are among the supplies that may be 
needed for the 9200. You should also investigate all other possible new filing require- 
ments. This should be done early enough so that needed items can be ordered and deliv- 
ered well before the computer’s delivery. Early delivery will permit you to check the new 
supplies to make certain that they meet all specifications. 


Cancellation of the Present Equipment 


It is important that cancellation of equipment to be replaced be planned early enough so 
that you will not have to pay rentals on idle machines. This withdrawal date must not af- 
fect the productivity of the Data Processing Department. 


MONITORING 


Actual conversion to the UNIVAC 9200 System can begin once conversion control has been 
established and conversion steps have been scheduled. This schedule must be faithfully 
followed and the conversion progress should be periodically reviewed. This procedure is 
known as Monitoring. 


Univac has prepared an Installation Pert Chart to assist the user in monitoring the total 
installation process including all of the above mentioned factors. 


This chart shows the relationship of factors involved in the conversion. It can provide 
the user with the general progress of the conversion at a glance. 


As the Data Processing Manager is responsible for the installation of the new computer, 
he should monitor the progress of conversion. At least once a week he should update the 
four planning forms provided by Univac: 


a Program Inventory List 

gw Workload Scheduling Chart 
w Program Check List 

w Installation Pert Chart 


After the forms are updated, he should review them to compare the progress of conversion 
to date with the scheduled progress to date. He will thus be able to spot problem areas 
before they become critical and, whatever their causes may be, to take corrective action 














to bring the work back on schedule. Monitoring will also enable the Data Processing 
Manager to keep his management regularly informed of the progress of conversion. 


If the conversion work is not progressing according to schedule, four types of corrective 
action can be taken: 


Increase the productivity of the Data Processing Department 
Use outside help 

Temporarily rent additional equipment 

Reschedule the conversion work 


Increasing Productivity 


The work schedule and working conditions are the two areas that can most effectively be 
improved to speed conversion work. It is possible that personnel working on the conver- 
sion are hindered by other duties. If this is so, their productivity can be raised by as- 
signing their nonconversion duties to other people, if possible. Working conditions should 
provide sufficient space and quiet to allow personnel to work without distractions or in- 
terruptions. If neither the work schedule nor working conditions can be improved, it may 
become necessary to put personnel on an overtime basis or to use outside help. 


If permanent personnel are used on an overtime basis, care should be taken that their over- 
familiarity does not adversely affect the accuracy of the conversion. The tendency exists 
for special cases to be carried forward because the operator knows the circumstances and 
how these exceptions are handled under the old system. In any event, a staff supervisor 
should be given the responsibility of controlling the conversion. 


Use of Outside Help 
This can take two forms: 


a Temporary personnel 
m Conversion by a service bureau 


Temporary personnel are often hired for simple card reproduction operations. Their ac- 
curacy and their knowledge of how to handle special case cards may not, however, match 
those of permanent personnel. They will require close supervision and can thus represent 
an additional supervisory burden. 


Conversion by a service bureau will usually be efficient and on schedule. It may, however, 
present some control problems, and will require the reproduction or temporary release of 
working files. One of the advantages of this approach is the lesser burden which it places 
on installation personnel at a time of peak activity. 


Rescheduling Conversion Work Fe 


If no internal improvements can be made, it will be necessary to reschedule the conver- 
sion. Small monthly jobs and others that are not run daily or are not absolutely neces- 

sary for successful operation can sometimes be scheduled as last for conversion. They 
can then be run outside after the new system is installed until they, too, are converted. 


If delays in the progress of conversion are such that the Workload Scheduling Chart must 
be modified, it will usually not be necessary to recreate the entire Chart. Only starting 
and completion dates on the graphic portion of the Chart need be altered. The dates on 
the Installation Pert Chart can also be changed, if necessary. 


During conversion, higher management should be kept informed of current progress so that 
it may provide effective support to any area that requires it. In addition, the Univac Sales 











Representative will cooperate in meeting difficult problems that may arise. Through the 


Sales Representative, Univac will be kept constantly aware of your progress and of your A 
needs. 
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Ht. DOCUMENTING 
THE PRESENT SYSTEM 


INTRODUCTION 


The cutover of existing applications to the UNIVAC 9200 System is no exception to the 
rule that any kind of accomplishment must be based on thorough knowledge of the work to 
be done. Before any application system design or programming can begin, it is necessary 
to prepare complete records of every operation for each application. This documentation 
task is no less important than actual programming, for its accuracy and completeness will 
underlie your entire conversion. In addition, the thoroughness with which you can 
assemble this information will govern the speed and accuracy with which you can convert 
to the new computer. 


To aid you in documenting your present application, Univac has designed an easy-to-use 
documentation method and related work forms. They are specifically designed to record 
your existing procedures in such a way as to reveal any changes that must be made for 
conversion to the 9200. As a result, subsequent programming will be much easier and 
cutover to the new system will be expedited. 


Both the Univac method and associated forms are fully described in this chapter. They 
will help you perform the four functions that are basic for a successful documentation 
effort: 


@ Flowcharting the application 

= Documenting operations for each run 
m Recording documentation progress 

@ Final Review 


THE UNIVAC METHOD 


The Univac Documentation method provides a way to systematically record existing 
application information with maximum ease and in a simple, standardized action format. 
This information describes input, output, frequency and volume for each run within an 
application. It is arranged in a manner that enables you to eliminate the need for 
intermediate steps and quickly determine runs, input and output that should be eliminated, 
combined or otherwise modified for optimum use of the UNIVAC 9200. Documentation can 
best proceed on an application-by-application basis. Recording of one application should 
be completed before documentation of the next is begun. Information thus assembled is 
entered on four related work charts. They are: 


@ Application Chart 

@ Multiple Card Layout Chart 

@ Printer Format Chart . 
@ Program Logic Chart 


The Application Chart is used to chart individual runs for analysis of functions and 
data flow. The Multiple Card Layout and Printer Format charts serve to document run 
inputs and outputs, and the Program Logic Chart is used to record operations occurring 
within each run. As you use these charts to document successive applications, you 
should keep a record of your progress. Your documentation should be reviewed after 
completion to make sure that it covers the requirements of each application. It can then 
be used to support the subsequent application development and programming phases 
described in Chapters III and IV. 
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FLOWCHARTING THE APPLICATION 


For effective flowcharting, each application must be portrayed as a whole. All operations, 
whether machine or clerical must be shown and their inter-relationships easily visualized. 
Even minor functions must be included as their omission might cause wrong conclusions 
during the subsequent installation planning phase. Only a complete application chart can 
be analyzed to reveal time-saving consolidations of operations and procedures. 


The Univac designed Application Chart (See Figure IH-1) should be used to record appli- 
cation data. It contains a series of American Standards Association flowchart symbols so 
arranged that they may be connected to portray a function’s inputs and outputs and also 
picture the function itself. 


The Chart is divided into two vertical sections, each section holds symbols for charting 
of four different functions. The three types of symbols used on the form represent: 


w Operation or function 
@ Input or output document 
@ Input or output card 


The operation or function symbol is a rectangular box. 
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Figure {I-1. Application Chart 


There are spaces within each box in which to enter the operation number, the number of 
the machine on which it is performed, and a brief description. Additional input or output 
symbols may be drawn to the left of the operation box if needed. 
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To portray the operation, lines are drawn to connect its various elements. Blank, uncon- 
nected symbols are disregarded. A flowchart can thus be formed by connecting lines a 
between separate operations, with the output of the first becoming input to the next. 

Symbols for input or output documents and cards should contain a brief description or 

report name and the average volume of cards or number of document lines. This volume 

information is an important consideration for proper planning of application revisions. 

The frequency information noted in the operation box is also important. It can be abbrevi- 

ated to read ‘‘D’’ for daily, ‘‘W’’ for Weekly, etc. It is important that full information be 

noted in each operation box. 


Connectors designate card files that have come from some previous operation or are to be 
used in some subsequent operation, not directly in sequence. A connector is a circle 
containing a number that serves as a reference point. A triangle may be used as a symbol 
for a file or storage point. 


Flowchart Information 


Internal information may be available to aid in the preparation of an application flowchart. 
This information should, however, always be carefully reviewed for errors, omissions and 
obsolescence by someone familiar with the application, even if it seems complete and up 
to date. 


@ A previous flowchart of the application provides the most useful documentation. If 
complete and up to date, it can be used as is. Otherwise, it can serve as a guide for 
the new chart. 

@ An operations manual is almost as useful as a flowchart. However, even if the manual 
is complete and up to date, a chart should still be drawn so that the application can be 
quickly visualized as a whole. 

m@ An operation-by-operation record of an application may be made during machine-process- 
ing if no adequate documentation is available. The operator should record every 
operation as he performs it, and even special reports and other operations that are 
performed only infrequently. 


Each flowcharted application and every operation within it must be identified and be listed 
on the Program Inventory List (see Chapter I). Each application should be assigned a 
letter designation, usually the initial of its name, such as ‘‘P’’ for Payroll. No more than 
three letters should be used. Each operation is then assigned a number, indicating its 
place in the operations sequence. It is recommended that operations be numbered by ‘‘tens’’ 
to reserve unused numbers for later additions to the application. The first operation would 
thus be numbered 10, the second 20, and so forth. In this way, every change in an oper- 
ation can be easily recorded as it occurs. The flowchart will thus reflect current operations 
at all times, and continue to provide the benefits of good documentation. 


An example of how the Application Chart may be used to flowchart an application is pro- 
vided in Figure II-2. A segment of a typical payroll is to be charted and it is assumed 
that time cards have been previously gathered, punched extended and the weekly payroll 
cycle is now being performed. The letter symbols on the chart refer to the following 
significant aspects of the flowcharting procedures: 


A. A connector from the preceding page of the flowchart binder indicates the source of 
the input cards. They are briefly described and their volume is entered in the input 
card form. 
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Figure 11-2. Payroll System Flowchart, Sheet I of 4 
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Figure 11-2. Payroll System Flowchart, Sheet 2 of 4 


















B. Information entered in the Operation 110 box shows that this is a sort operation on an 
083 sorter, that the sort is by employee and department and is performed weekly. 


Five hundred blank summary cards are required as input for the next operation. 


Processing of detail time cards for this operation has been completed. This is indi- 
cated by a ‘‘file’’ symbol drawn after the output card form. 


E. Connector ‘‘2’’ indicates that the ‘‘Deduction Master’’ card file is now entering the 
application flow. 


F. The second card drawn behind the first indicates that the two different card files 
have been merged into one. 


G. The gross pay summary cards will re-enter processing flow on the next page of the 
chart binder. Its origin will be referenced by the connector. 


As you chart each application, you are likely to remember inefficient procedures that 
could not be remedied before, to uncover new ones, and to discover ways in which system 
operations could be simplified and improved. This information should be carefully re- 
corded for the planning phase that will follow, either on the relevant flowchart or on an 
attached listing. Deficiencies to be noted include operations that should have been per- 
formed in the past, but were left undone due to time or equipment limitations. Also to be 
noted are the possibilities of simplifying the processing sequence that become evident 
during flowcharting. These consist largely of duplicate, similar or obsolete report require- 
ments that were ‘‘tacked on’’ to an existing application and create needless additional 
operations. When operations are reprogrammed for the new system, it will be possible to 
meet some present requirements through by-products of other operations. 


Interrelationships of cards and reports between applications should be set down. In this 
way, provision will be made for them during the planning phase and conflicts between 
applications will be avoided. 


DOCUMENTING RUNS 
Each run within an application must be fully documented to indicate: 


a Input and output card formats 
a Printer output formats 
@ Calculation details 


The following paragraphs describe the three simple charts provided by Univac to aid 
you in recording run documentation: 


@ Multiple Card Layout Chart . : 
@ Printer Format Chart 
@ Program Logic Chart 


The Multiple Card Layout Chart (See Figure II-3) has six cards per page on which to 
record data for individual input or output cards. Card names, control positions and other 
pertinent data are recorded in the spaces provided at the left of each field. This informa- 
tion will be used later for new system programming. 
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Figure I1-3. Multiple Layout Card Chart 
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Figure Il-4. Printer Format Chart 


The Printer F ormat Chart (See Figure II-4) is similar to other printer charts, save for 
several information columns on the left of the chart. Information from these columns on 
the left of the chart will be used in the subsequent application development phase. 


The Program Logic Chart (See Figure II-5) is used to describe the logic of each program, 
regardless of the equipment used. Operations should be described in plain English, not 
equipment terminology. 


Several sources of documentation may be available in-house to provide run documentation. 
Run definition charts are the most useful sources, if they are available. Even if they are 
not up to date, they can still provide guides for new charts. Written run definitions can 























also be useful, but even if the text is complete, charts should be drawn for complete under- 
standing of data flow. If no run documentation is available in-house, it may be necessary 
to resort to a test run and an analysis of the plugboard wiring. 


Each run that is to be documented must be detailed as to exact card formats, both input 
and output, printer formats and specific information pertaining to all calculations per- 
formed. All of these must be recorded accurately and completely in order that planning 
and programming for your UNIVAC 9200 computer may proceed without delays caused by 
insufficient:information. Time spent at this point will pay dividends in programs being 
written quickly and accurately. 


The following paragraphs provide examples of recording methods for the Multiple Card 
Layout Chart, the Printer Format Chart and the Program Logic Chart. 


@ Multiple Card Layout — the method to be used for entry of data on this chart is illus- 
trated in Figures II-6, 7, 8 and 9. In all cases, a master chart records all of the cards 
used for a payroll application. However, not all the cards will be used in each run. 
The master chart will be reproduced for each run to be documented, and the cards not 
used for that run will be crossed out. 


Information not pertinent to all runs, such as total control columns, input and output, 
etc., is omitted from the master chart and filled in for each run chart for which it is 
pertinent. The name of the application, the run number, the name of the individual who 
prepared the chart and the date of preparation should be shown across the top of each 
run chart. 


The boundaries of each card field are shown by lines drawn between the proper column 
numbers. If a field is common to more than one card, the lines are extended downward 

from the first to the other cards. Each field on each card should be identified by name. 
To conform with subsequent programming requirements, this name should consist of not 
more than six alpha/numeric characters and not include spaces and special characters. 


uw Numeric fields, those which are involved in calculations or are numerically sequenced 
(see Figure II-6), must also show decimal points. A small triangular symbol, known as 
a ‘‘carat’’, is inserted between columns to indicate the decimal point. Any numeric 
field that is expressed as a whole number should have a carat placed on the vertical 
line at the right margin of the field. Credit positions applying to individual fields 
must also be shown. 
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Figure 11-5. Program Logie Chart 
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Figure II-6. Sequencing of numeric card fields 





a Control positions that identify cards and card names should be entered in the space 
provided for this purpose at the left of the chart (See Figure II-7). 


@ Total level control fields (See Figure II-8), the card fields that cause automatic total 
breaks, will vary from run to run. This information must therefore be entered separately 
for each run. The fields are recorded by extending the vertical separator lines upward 
into the ‘‘total level’’ tier at the top of the chart. The class of total (major, minor, 
intermediate) is then entered in the resulting new box. 


m Sequencing, number and optional presence (See Figure II-9) information varies from run 
to run. It is entered in the four boxes at the left of the chart (below ‘‘Card Name’’) 
under the four following abbreviated headings: 


a I/O g@ No. Cds. 
m SEQ m OPT 


a I/O column indicates whether a given card type provides input or output in this run. 
Either ‘‘I’’ or ‘‘0’’? should be marked in the column, or both if the card combines input 
and output functions; that is, if output data is punched into the same card as was used 
for input. 


@ SEQ indicates the sequence in which a particular card type is processed during a run. 
If the card is the first to be processed, the ‘‘1’’ should be entered in the column, a ‘‘2’’ 
if it is to be second, and so forth. An ‘‘A’’ is entered if sequence of card types has 
no significance. 


@ No. Cds. column shows whether only one or any number of cards of a given type may 
appear in a control group. Either the ‘‘1’’ or ‘‘MUL’’ should be marked. 
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Figure 11-7. Entry of Control Positions of Multiple Card Layout Chart 
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Figure 11-8. Multiple Card Layout Chart-total level control fields. 
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Figure (1-9. Multiple Card Layout Chart, sequencing, number and optional presence entries. 
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= OPT column contains an ‘‘0’’, to show that a given card type may or may not be 
present in a control group, that is, its presence is optional. 


Any additional data that may help describe a card should also be recorded. If necessary, 
notes may be attached to the Card Layout Chart. 


Printer Format Chart. Printing format information can usually be obtained from a copy of 
the existing printout. This printout should show output from all individual cards and 
indicate all special vertical spacing and skipping requirements. Sometimes more than one 
printout page should be included to show all possible conditions. If no printout is avail- 
able, however, the Printer Format Chart should be used to record printing data. The top 
of each chart should carry the application’s name, run number and other pertinent data. 
Within the work space, at least two detail lines can be entered by positioning XXX’s, 
filling out the maximum size of each field (See Figure I-10). Any totals printed, should 
be entered in the same fashion. To aid later evaluation, page and column headings 

must be entered in the appropriate spaces, even if they are not shown on existing forms. 


The layout must show all editing features. These include: 


special symbols 
check protection 
total and credit indications 
decimal and comma printing 


Notes can be entered in the layout to indicate desirable editing characters that cannot 
now be printed because of current equipment limitations (See Figure II-11). 


Chart notations should include all vertical spacing and skipping requirements, including 

the normal overflow to following pages. Forms that require eight to the inch spacing a, 
should have a special note to that effect. The chart should contain a short summary of 

forms construction, particularly of those forms that have special fastening requirements 

as spot carbon, snap-out set, etc. 
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Program Logic Chart is used to state the logic of a run. This is a ‘‘problem statement,’’ 
not a description of how the present machine actually processes that run. One chart is 
usually enough for this purpose. The application name, run number and other pertinent 
data should be shown across the top of each page. Chart statements should be in plain 
English with the algebraic signs +, >, <, #, —, x, |, =, used to describe operations per- 
formed. Machine terminology should not be used. 


The Program Logic Chart is divided into six main columns: 


a Card Type 

@ Condition and/or Control column contains control positions that identify cards or special 
conditions during calculation. 

a Step column identifies step numbers. There is no requirement that step numbers be con- 
tinuous or consecutive. They are to be used as reference points. 

@ Description of Operation column contains a series of logical statements, arranged in 
sequence, defining the problem solution. 

@ Branch column is used when a condition is created by the logic that causes the problem 
solution to take an alternative path. There are two sub-columns: Condition and To. 
The first states the condition that causes the branch, and the second shows the first 
step in the alternate sequence to be ‘‘jumped’’ to. 

@ Comments column shows the number of positions needed in the result, if this has not 
been made apparent through previously defined fields and the number of decimal places. 
Other comments helping to sharpen logic definition should also be entered. 


The use of the Program Logic Chart is demonstrated by Figure 11-12. The calculation 
run illustrated is numbered P220 (calculation of Canada Pension Plan contributions and 
Taxable Income) on the Application Flowchart. Input for this run is the Gross Pay 
summary card which contains the following information pertinent to this run: 


@ Gross Pay 
@ Deductions per TD1. 
@ Year-to-Date Canada Pension Plan contributions. 


During the run, the Canada Pension Plan contribution for the current period must be 
calculated and punched into the Gross Pay summary card. The Gross Pay amount is 
reduced by the Canada Pension Plan Contribution and the calculated weekly equivalent 
exemption from the employees TDI form. The resulting Taxable Income amount is 
punched into the Gross Pay summary card for subsequent use in the determination of 
income tax to be deducted for the current pay period. 


The Gross Pay summary card is described in the Payroll Multiple Card Layout Chart (see 
Figure 11-13). Other payroll cards not required for run P170 are not included on the copy 
of the chart for this run. . 


Significant factors to be considered in developing the Program Logic Chart are indicated 
by the letter references in Figure 11-12. 


A. The card type describes the card as a Gross Pay summary card. 


B. The control position indicates that the card is identified during a run by a ‘‘4’’ punch 
in column 80. 


C. In step 1, a test is made to determine if the maximum Canada Pension Plan Amount 
has been previously deducted. If the maximum has been reached, the remainder of the 
steps for the Canada Pension Plan routine (steps 2 to 8) are bypassed. 


D. ($11.54) indicates a constant value. The basis for using this value is indicated in the 
comments section. 
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Figure 11-12. Program Logic Chart, payroll calculating runs. 
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E. Step 5 indicates that the C.P.P. amount is rounded. aie 
: . : : : ~/ 
F. Since the size of the card field does not reflect the true size of the result field and 
since it is not otherwise apparent, it is noted in the comments section. 


The operations that are required to be shown on the Program Logic Chart are those 
concerned with calculations and with testing numeric values. It is often not necessary to 
show movements of fields such as name and department number. 


An example of print and punch operations is illustrated in Figures 11-14. The purpose of 
the Program Logic Chart for run P300 (punch new Year-to-Date summary cards and print a 
Control Register), is to illustrate clearly the accumulation of data for punch and printer 
output. The Gross Pay summary cards and Year-to-Date summary cards are used as input. 
Operations to be performed are shown in Figure 11-14. A Multiple Card Layout Chart 

for run P300 is illustrated in Figure 11-15. 


Significant factors to be considered in developing the Program Logic Chart are indicated 
by the letter references in Figure 11-14. 


A. Steps 1, 2 and 3 accumulate three fields which are to be updated. Fields in the last 
period Year-to-Date summary card are added to zero to show a clear counter. 


B. Steps 4, 5 and 6. accumulate current period amounts before a new Year-to-Date 


summary is punched. 


C. Steps 7 through 12 accumulate control totals, both to-date and current period, for each 
of the three fields. 


D. xxxxxx.xx indicates the maximum possible number of digits to be accumulated. 


Only Operations that involve calculations are shown. There is usually no need to 
describe operations in which data is transferred solely for printing or punching purposes. 
Their nature should, however, be carefully examined. What may essentially be a punch- 
ing operation, if your present card equipment does not include a calculator, may be a 
calculating operation for a computer. As an example, it is possible to multiply without a 
calculator through the use of a complete deck of master cards containing the extension of 
every normal calculation. Detail cards are merged behind matching masters and the 
extensions are matched and gang-punched on a reproducer. A set of run definition charts 
should always be created for this type of collator-reproducer run, if it is used. 


During the creation of the Program Logic Chart, it is extremely important that the number 
of decimal positions and the maximum size of result fields be specified if they are not 
readily indicated by previously defined fields. Preferably, they should be entered in the 
Comments column, as illustrated by Figure II-16. Control totals developed during a run, 

but not included in the normal output may be ‘‘spilled out’’ in a special operation at the 
end of the run. A separate card pass is often used to develop these totals which must be 
thoroughly documented. Any other pertinent data that will aid in describing a given logical 
operation should be written down and attached to the logic chart. It is most important 

that all data be committed to writing to insure a complete and accurate conversion. 
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Figure 11-14. Program Logic Chart, Payroll Operation P300. 
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Figure 11-15. Multiple Card Layout Chart, Payroll! Operation P300. 
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Figure Il-16. Program Logic Chart, specification of decimal positions and field boundaries. 
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RECORDING DOCUMENTATION PROGRESS 


You should control the progress of your documentation effort to make certain that it is 
being accomplished thoroughly and according to schedule. For this purpose, you should 
use two check lists, the Program Inventory List and the Workload Scheduling Chart. 





Entries were made on both Univac designed forms before documentation began. The na- 
ture and instructions for their posting are thoroughly described in Chapter I. 


a Program Inventory List. As soon as documentation is completed for a given run, the 
Input, Output and Logic list columns for that run should be checked. 


w Workload Scheduling Chart. This list should be checked as soon as documentation for 
an entire application is completed. 


FINAL REVIEW 


After all applications and runs within the existing system have been suitably recorded, a 
final review must be conducted to insure that the documentation is both complete and 
accurate. This review should preferably be done by individuals familiar with the opera- 
tions covered. 


A detailed review of completed documentation will insure that all periodic application 
requirements have been met. Records must cover processing on a daily, weekly, monthly, 
quarterly and annual basis, or for as often as the runs must be performed. Similarly, 
where one application is linked to another, documentation for both applications must re- 
flect this inter-relationship. 





Completed documentation should be filed in a binder by application. Records of the indi- 
vidual runs should be filed by run number within the application. The Application chart 
should be filed in the front of each application section in the binder. After documentation 
has been placed in a binder, it should be carefully indexed, and the pages numbered, so 
that any information desired is easily available for reference. If more than one binder 
must be used, they should be carefully labelled as to their contents, and this information 
should be recorded in the index. 
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lil, APPLICATION DEVELOPMENT 


INTRODUCTION 


This chapter provides the bridge between the documentation of the present system (see 
Chapter II) and its application to the UNIVAC 9200. It describes the simple conversion 
techniques and related work forms that will enable you to use the information on the ex- 
isting system to determine how each application should be run on the 9200, taking fullest 
advantage of the machine’s capabilities. The complete and accurate documentation of the 
new system that will result will underlie the subsequent preparation of 9200 programs 
described in Chapter IV. 


This phase of the installation of the UNIVAC 9200 probably involves the largest number 
of decisions, and the Univac Sales Representative’ and the Univac Systems Analysis staff 
are ready to assist you. Decisions should be made in the light of your particular require- 
ments, such as the need for new or more detailed reports or the running of additional ap- 
plications on the 9200. Knowledge of these needs will help you determine which of the 
two following alternate approaches to the conversion method should be used for each 
application. 


a Straight conversion, the carryover of each present equipment run to an equivalent com- 
puter run on a one-for- one basis. 

a Consolidation of several present operations into a single 9200 operation for better 
throughput and greater efficiency. 


Another method of conversion, System Design, is also described in this chapter. The use 
of this method, which involves the entire redesign of an application, is, however, quite 

difficult and time-consuming. It is recommended only for new applications or in instances 
when a clear need exists for the drastic reorganization of an existing system. 


STRAIGHT CONVERSION 


Even though runs are to be carried over ‘‘as is,’’ carryover planning will still require 
close analysis and, in some cases, documentation changes prior to programming, particu- 
larly for the following: 


a Printer Format Chart 
a Multiple Card Layout Chart 
a Program Logic Chart 


Printer Format Chart 


The chart (described in Chapter II) may have to be revised to reflect changes in printer 
format, such as conversion to 10 to the inch spacing and possible compression or expan- 
sion of data fields that were restricted under the old system. 


Multiple Card Layout Charts 


You may wish to modify card input and output designs to take advantage of the power of 
the 9200. Even though existing formats can usually be effectively used for the new sys- 
tem, it is well to review them to determine whether any minor changes might be appro- 
priate under some circumstances. These may include changes in control punching which 
will have to be extended to related summary cards. 
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Program Logic Chart 


After card inputs and outputs have been analyzed, the Chart (described in Chapter II) 
should be revised for any minor changes that may be required for the transfer of a run to 
the new equipment. 


CONSOLIDATION PLANNING 
Planning the consolidation of present runs involves three basic functions. 


a Defining runs to be consolidated 
a Analyzing runs to be consolidated 
w Updating documentation. 


Defining runs to be consolidated 
Three types of runs can usually be consolidated. They are: 


a Multiple Calculation Runs 
w Calculation followed by Print Runs 
m Multiple Print Runs 


Multiple Calculation Runs, The capacity and speed of the UNIVAC 9200 System permit 
one-pass operations where two or more would be required on unit record calculators. 
Figure III-1 portrays unit record processing of a typical invoicing application. A small 
punched card calculator might require two passes to perform the operations necessary to 
extend the item cards, take discounts and apply sales tax. 


Calculation Followed by Print Runs. The 9200 can simultaneously edit and print reports 
and perform calculations on input data. This makes it possible to consolidate as one the 
unit record runs which use the output of a calculating run as immediate accounting machine 
in put for production of a pririted report. Figure III-1 also provides such an example. The 
invoice detail or item cards are extended in one pass through the calculator and an 
accounting machine then prints and totals the customer invoices. Figure IH-2 shows 

how the 9200 System can perform these several runs in one pass. 


Multiple Print Runs. Using unit record equipment, it is often necessary to process a file 
two or more times to print and total information for a simple report. This is caused by the 
equipment’s lack of sufficient type bars to print through the desired width or counters to 
create the totals needed. The calculator’s limited capacity may also prevent generation 
of all the results needed for the report. In the last case, as many as two calculations and 
two print runs may be needed. 


Figure III-3 portrays a typical example where the counter capacity of the accounting mac- 
hine cannot carry the totals required for a report. It then becomes necessary to print q re- 
port with two to three levels of totals and also to create summary cards. The latter are 
then tabulated to generate the additional totals required. Figure III-3 pictures how the 
UNIVAC 9200 permits these two runs to be combined, and one comprehensive report to be 
produced instead of two. 


Analyzing runs to be consolidated 


Several factors must be carefully considered to determine whether a consolidation is 
feasible: 


m Consolidation logic 
m Effects on production schedule 
m Cycle or frequency of runs 
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w Complexity of programming 
m Equipment capability 


Consolidation logic. Two considerations must be examined: 


1. Does the present or proposed flow of data allow a given consolidation? 
2. Does the output of one run provide immediate input to the next, or are intermediate 
card-handling operations necessary? 


Even if intermediate card-handling is required, runs can sometimes still be consolidated. 
For instance, if the output of a calculation run requires merging of header cards before 
printing, the merge can precede the calculation, and a consolidation is thus feasible. 


It must be determined whether intermediate outputs can be eliminated through consolida- 
tion or whether they are needed for later runs, and also whether card output is needed for 
visual reference for audit purposes. 


Effects on production schedules. Before consolidation, the overall machine room schedule 
and the preparation of reports must be considered. 


Cycle or frequency of runs. Consolidation of two or more operations into one is most re- 
warding for high-volume mns whose frequency is higher than quarterly. 


Complexity of programming. The value of combining two or more runs depends on the com- 
plexity of the resulting program. In many cases, this program is simple enough to mate- 
tially reduce the running time of the consolidated run. 


Equipment capability. While some consolidations may be accommodated by the UNIVAC 
9200, consideration of peripheral equipment capacities should be reviewed. This could 
affect machine room scheduling and report timing. 


It might for instance, seem logical to produce Summary cards during a summary report 
preparation run. However, it is possible that 2 passes of the detail cards would provide a 
faster throughput since the UNIVAC 9200 card reader is faster than the summary punch. 


Updating documentation 


When two or more programs are consolidated, the pertinent documentation must be revised. 
Included in this revision will be updating of: 


@ Input/output forms 
m Program Logic Chart 


Input/Output forms. As consolidations occur, inputs may have to be modified or combin- 
ed. Similarly, card output may require redesign to include information from. more than one 
run. Intermediate card and printer outputs may be eliminated when runs are combined, and 
the final printer format may be changed considerably as multiple print runs are consoli- 
dated. To reflect these changes the following documentation forms must be updated: 


a Multiple Card Layout Chart 
g Printer Format Chart 
gw Program Logic Chart 


The Program Logic Chart. When several programs are consolidated, all run inputs and 
outputs must be reviewed and the Chart should be re-written to reflect the new single data 
flow. 
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Figure Ill-1. Billing — Unit Record Procedure 
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The combined approach 


A combination of both the Straight Conversion and the Consolidation approaches will 
often be used in converting various runs within an application. The flexibility of this ap- 
proach is extremely useful as it permits simultaneous enjoyment of the simplicity of 
carryover and the improved efficiency of consolidation. Each conversion approach, how- 
ever, has its particular requirements, and runs to be converted should be examined in the 
light of these needs. 


SYSTEM DESIGN 


Existing applications can usually be easily carried over to the UNIVAC 9200,using either 
Straight Conversion or the Consolidated approach, or a combination of both. However, the 
great power and throughput of the 9200 will allow many applications to be run on the com- 
puter which it was not practical to put on a machine before. Complete new systems will 
have to be designed for these applications and a design method recommended by Univac 
is described in this section. It is designed to aid UNIVAC 9200 users who, having suc- 
cessfully converted previous applications to the new system, now seek to develop addi- 
tional applications to make fullest use of equipment capabilities. 


The design method follows the pattern recommended by Univac for other conversion tasks 
— the performance of the actual conversion work being preceded by a careful definition of 
objectives which the new system must meet. The two major system design functions there- 
fore are: 


w Investigation 
m Development 


System design is the study and creation of manual or automated procedures to accomplish 
specific objectives. Systems can be designed for many reasons, but must always be de- 
signed logically. The system’s objectives, its effect on other systems and its operating 
economy must always be kept in mind. Comprehensive and effective system design should 
be carried out in close liaison with management. 


Investigation 


Production of output information is the main purpose of any system. Therefore, to deter- 
mine the objectives which the system must meet, you should define the output information 
which it must produce. Similarly, the input data and the procedures which will create this 
information must also be examined. These definitions must be complete in every detail 
and clearly expressed in a standardized manner that will allow no misinterpretation. 


System design information. Comes from two chief sources: existing records and individ- 
uals responsible for work which the system will cover. Records include work papers, step- 
by-step procedures and Data Processing Department material such as flow-charts, input/ 
output records, procedures write-ups, etc. 


No one system is quite like any other. However, if you use the following general ques- 
tionnaire outline, omissions will be kept at a minimum andyou should be able to quickly 
determine how the questionnaire must be modified. Correct and complete answers to the 
following questions will provide basic data for a successful system design investigation. 


(1) What is the prime application area? 

(2) What are the specific operations involved? 
(3) What is the purpose of the operation? 

(4) Who is responsible for the operation? 

(5) Is it automated or manual? 
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(6) What documentation is available? 


Automated Procedures 


(a) process charts? 

(b) procedure charts? 

(c) source and input media? 
(d) processing functions? 
(e) output formats? 





Manual Procedure 


(a) procedures manual? 

(b) job descriptions? 

(c) workpapers? 

(d) tables and charts used? 
: (e) forms? 
at (f) equipment used? 


(7) Is available documentation up to date? 

(8) What is the volume or workloads? 
; (9) What is the processing cycle time? 
: (10) What is the processing frequency of the operation? 
(11) What are the exceptions and how are they handled? 
(12) Is the work flow steady or irregular? 
(13) What is the previous operation — the next operation? 
(14) What controls are exercised? 
(15) Are there any legal requirements? 











These questions are general in nature and not specifically directed toward analysis of 
any particular application. Their answers, however, will suggest more specific queries 
conceming definite applications. The investigation must also cover application work 
papers, restrictions and controls. 





a Work papers. Their functions are varied, but they usually provide management with cur- 
rent information. Work papers can be classified into three groups according to their 
functions: 


@ reports 
gw forms 
@ records 


Each item must be examined to check whether it meets the requirements of the task for 
which it was designed and is now used. 


a Restrictions. Sometimes company policy or legal restrictions cannot be modified, and 
their effect on the new system must be carefully noted. 


= Controls. During the systems investigation, all control for the application must be 
listed. Their types will vary, depending on the application and your organization’s 
activities, but the following questions must be answered: 


What are the input controls? 
What are the output controls? 
Is there an audit trail? 

Are there excess controls? 
Are there enough controls? 
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Review. After the investigation is completed, you should perform a step-by-step check of 
each operation in the sequence in which it occurs to check how well it meets system ob- 
jectives. Both new and previously existing documentation must also be examined for cla- 
rity, accuracy andcompleteness. This is the time at which you should make any changes 
in procedures. 


After you have completed documention and review of the entire system, it is recommended 
that you have your findings checked for accuracy by the various people involved with the 
system’s procedures. You can then resolve all differences of opinion and, if necessary, 
modify system documentation before submitting your recommendations for management 
approval. 


Some applications can best be handled as manual operations, because of time, cost and 
low volume. The results of your investigation can, therefore, be summarized into the an- 
swer to a single question — ‘‘Should the application be automated?’’ If this answer is 
“"Yes,’’ you can then proceed to actual design of the new application system. 


Development. After all necessary information has been collected to document the appli- 
cation, the actual design of the new system can begin. This procedure involves the per- 
formance of two basic functions: 


a Definition of new system requirements 
a New system flowcharting 


Definition of new system requirements. Actual system design must begin with a thorough 
study and re-evaluation of the information assembled during systems investigation. This 
will enable you to determine the following requirements and considerations for the new 
system: 


Output 

Data files 

Input 

Procedures 

Workload and timing 
Equipment specifications 


These determinations will indicate the approaches to be followed in the subsequent ap- 
plications flow-charting phase. 


a Determination of required output. Decisions as to which applications or runs can be 
eliminated, modified or combined depend largely on such output factors as the needs of 
various department, company policy and legal requirements. The nature and usefulness 
of each output item must, therefore, be determined. This determination involves ques- 
tions such as whether system revision can reduce the number of copies which must be 
made of a form, or whether this form is small enough to print two-up instead of one 
original and one carbon copy. As the number of carbons in a form, rather than the size 
of the paper, influence its price, a run can be made much more economical through the 
elimination of unnecessary copies. 


The following questions can be asked of the people who use a given report in order to 
justify its production in its present form, and to determine how it can be improved or if it 
should be eliminated. 


How many other persons use it? 

How essential is it to the work of your otganization? 

How often do you use your copy of the report? 

- How much of the information on the report do you not use? 


-Fwne 
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8. 
9. 
10. 
11. 
12. 
13. 


Is the data necessary for: 

a. making action decisions 7 
b. keeping you informed of current conditions 

c. checking accuracy of other information 

d. maintaining control over operations 


What would be the effect on your work if: 
a. you did not get the report at all 

b. seldom received the report 

c. the report contained less information 
d. the report contained more information 


. Do you consider that your use of this report justifies the cost of preparing the report? 
What other reports, records or forms are prepared from data on this report? 

Can the data on this report be obtained from any other source? 

How long do you keep your copy of the report? 

Is this report easy to use and read? 

How and where do you file it? 

How often do you refer to it after its original use? 


Description of required data files. There are two types of data files: 


a Master files 
@ Transaction files 


Master files contain permanent records concerming an organization or functions of that 
organization. Examples are name and address files, inventory files, and accounts re- 
ceivable files. 


Transaction files are data files whose contents are run to update the master files. Ex- 
amples are files of payment cards, time cards, anditem cards. A transaction file may, 
for instance, be used to update such year-to-date information in a payroll master file 
as: 
—™ gross pay year-to-date 
@ total Income Tax year-to-date 
@ Canada Pension Plan year-to-date 
@ Total deductions year-to-date 
It will not, however, serve to update other master card information such as: 
m employee number 
mw exemptions 
@ insurance 
@ bond purchase plan . 
® union dues 
Some types of data files will require little maintenance while others will change with 
each processing cycle. In any event, the continuity of these records must be insured. 
Description of required input. All types of source documents, such as time cards, in- 
voices, bills of lading, orders and requisitions, must be listed. Their progress from 
preparation through to the Data Processing Department must be traced to cover: 
1. Collection, verification and protection 
2. Establishment of batch total and recording = 
3. Establishment of controls to provide later audit trails ig 


: All input cards must be designed for maximum keypunching ease with minimum spacing 
YW between fields. In addition, the volume of cards to be handled should be reduced for 
better computer throughput. This is usually done during the design of the application. 
This volume may be reduced by consolidating the name and address cards, similarly, 
special cards should be eliminated as much as possible. 


Further throughput speed can be achieved through the elimination of punching some 
intermediate results as the speed of the 9200 could allow recalculation. In many unit 
record systems certain input and output card-columns are often used for controls and 
special card codes. These control columns must be carefully analyzed and any non- 
standard punching codes must be changed to standard codes. The reason for this is 
that, on the new system, cards are translated from card code to machine code as their 
data is read. Non-standard codes would, therefore, lose their identity during transla- 
tion and the resulting code would not permit suitable distinction. 


The sign of all arithmetic fields must be in the least significant location (LSL) in the 
field. In some cards, in carryover from older equipment, the sign positions were located 
at any point on the card. The sign must appear in the LSL of the field and the cards 
must be modified to meet this requirement. : j 








a Description of required procedures. The following information must be recorded: 


1. Keypunching of source data to create working documents 
2. Card-sorting sequence and merges with other data cards 
3. Use of cards to update certain files and produce history files 


It is recommended that, at this time, you update all block diagrams and make any re- 
quired changes of procedures. Most changes needed to improve the system have now 
been revealed. 


= Description of workload and timing considerations. When the system is designed, its 
work flow may be smoothed out to avoid activity highs and lows. Some of the factors to 
: be considered for this purpose are: 


reduction of waiting time 

elimination of bottlenecks 

advancing of cut-off periods 

processing of data before scheduled time 
scheduling mandatory applications first 
scheduling other applications as time allows 





Certain applications, such as payroll and cycle billing, which fall on the same dates 

as, for instance, month-end closing should be watched out for. All other work must be 
scheduled around these applications, and overtime work may be required unless their 

| processing can be completed during the next business day. 





m Equipment specifications. The 9200 System configuration will dictate the system ap- 
proach to be used. Aspects of equipment specifications which must be considered 
include: 


What is the size of the storage? 

Is the punch a read-punch? 

Will a UNIVAC 1001 card controller be used on-line? 
Number of print positions? 


and New system flowcharting. An application flowchart is the layout of the work flow by run 
, within the application. After reviewing the capabilities of the UNIVAC 9200 system, the 
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user can determine how much work can be accomplished with each computer run. In de- oN 
Signing the application, the user should strive to use the UNIVAC 9200 system to its S77 
fullest capabilities with the configuration available. Sometimes the configuration may be 

changed to gain additional benefits from the system. 


The following paragraphs portray the tasks required in the investigation and design 
phases of the creation of a new billing application system. The objectives of the appli- 
cation must first be determined through discussions with the three departments involved: 


m Sales Department 
g Billing and Accounts Receivable Department 
m Credit and Collection Department 


For this application, the output requirements of each department will be the following: 


a Sales Department — Sales Analysis Information by items, customer, territory and 
vendor. 


a Billing and Accounts Receivable — Daily Invoice and a Monthly Statement for record- 
ing activity of each customer account. 


g Credit and Collection — Aged Analysis for every account having a balance outstanding. 


After the application outputs have been defined, you should perform the following opera- 
tions: 


1. Draw up the actual output forms to cover all possible conditions. 
2. Review the forms with the Credit and Collection department and the Billing and 
Accounts Receivable department. 
3. Review Sales Department source data for completeness and flow. cc 


At this point when objectives have been determined, all departments concerned have 
agreed on the output and the source data has been reviewed, application flowcharting can 
begin. 


Figure III-4 illustrates flowcharting of procedures for production of daily invoice informa- 
tion, 


1. Data is captured from source documents. 

2. Working records must be verified. 

3. Item cards are then sorted into customer number sequence. 

4. Name and address and routing information cards are merged with item cards. 


Printing of daily invoices by the 9200 is portrayed in Figure HI-5. By-product invoice 
summary cards are created and retained for production of month-end statistical reports. 
After processing of invoices, name and address, routing and item cards are returned to 
the original files. 


Production of monthly statement information is required for the Billing and Accounts Re- 
ceivable Department. Run procedures are indicated in Figure III-6. 


1. Invoice summary cards produced daily are sorted into customer number sequence. 

2. Sorted invoice summary cards are merged with cards from the Accounts Receivable 
file, showing the balance outstanding as a total, and broken down by periods. 

3. Cards containing payment, credit and adjustment information are merged with invoice 
summary and accounts receivable cards to offset old balances outstanding. 

4. Customer name and address cards are merged with the file thus created. 
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Figure Ill—4. Production of Daily Invoice Information 





Figure I1!-—5. Printing of Daily Invoices 
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Figure I11~6. Production of Monthly Statement Information 
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Printing of monthly statements and aged analysis report are portrayed in Figure III-7. 


1. New updated accounts receivable cards are created as by-products of statement print- 
ing. 
2. Input card file for statement printing is sorted and: 


a. Payment, invoice summary and old accounts receivable cards are returned to files. 
b. Name and address cards are merged with new accounts receivable cards to provide 
input for printing of aged analysis report. 


3. Aged analysis report is printed. 
4. New accounts receivable and name & address cards are sorted apart and returned to files. 


If the Credit and Collection Department issues memos for accounts with credit balances, 
the accounts receivable cards must be modified to reflect these transactions. 


Monthly sales analysis reports must be printed for the Sales Department, breaking down 
sales by item, customer, territory, salesman, and vendor. Item cards originally produced 
from original sales documents provide input for the report. Sorting of the cards and print- 
ing of the sales analysis are portrayed in Figure III-8. The item cards are stored after- 
wards for a short period to provide reference data. 


After all runs for the application have been flowcharted, the design of the new system 
must be reviewed to check that it meets all specified requirements. When the new appli- 
cation system is approved by management, program flowcharting can then take place. 
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Figure II1-7. Printing of Monthly Statements and Aged Analysis Report 
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Figure I1i/-8. Monthly Sales Analysis Reports. 
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EXAMPLE 


The following is a sample Payroll Application documented on the forms recommended in 
this Planning Guide. The example shows this procedure as handled on conventional Tab- 


ulating Equipment and the corresponding run procedures using the UNIVAC 9200 approach. 


In this example, processing is carried on through the preparation of paychecks and eaming 
statements. 


UNIT RECORD PAYROLL RUNS 


P110 


P120 


P130 
P140 
P150 


P160 


P170 


P180 


P190 
P200 


P210 


P220 


P230 
P240 


P250 


P260 


Time cards, previously punched, rated, extended, and balanced to control, are 
sorted into Employee Number sequence within Department. 


Time cards are processed through the 407 Tabulator which summarizes the Gross 
Pay Register showing Department Number, Employee Number, and Gross Earnings. 
Gross Pay summary cards are punched by the 514 reproducer/summary punch. 

Time cards are filed for later use in preparing supplementary distribution reports. 


Gross Pay summary cards are merged with Master Miscellaneous Deduction cards. 
The Miscellaneous Deductions are reproduced into the Gross Pay cards. 


Master Miscellaneous Deduction cards and Gross Pay summary cards are separated. 
The Master Miscellaneous Deduction cards are filed. 


Unemployment Insurance Gangpunch Master cards are sorted with Gross Pay 
summary cards by Gross Pay amount. 


The 514 reproducer/summary punch is used to gangpunch the Unemployment 
Insurance Contribution amount into the Gross Pay summary cards. 


Gross Pay summary cards and Unemployment Insurance Gangpunch Masters are 
separated. Unemployment Insurance Gangpunch Masters are filed. 


Gross Pay summary cards are sorted by Employee Number within Department. 


Last period Year-to-Date summary cards are matched with Gross Pay summary 
cards to ensure that both files are complete. 


Last period Year-to-Date Canada Pension Plan Contribution amount is reproduced 
into the Gross Pay summary cards. Last period Year-to-Date summary cards are 


filed. 


The 604 Calculating Punch is used to calculate current period Canada Pension 
Plan Contributions and Taxable Income. Results are punched into the Gross Pay 
summary cards. 


This pass on the 604 verifies the calculation of run P220. 


Income Tax Factor cards and Gross Pay summary cards are sorted by Taxable 
Income amount. 


The 604 Calculating Punch is used to calculate Income Tax and to develop the 
Net Pay amount for the current period. Results are punched into the Gross Pay 
summary cards. 


This pass on the 604 verifies run P250. 


C) 























P270 


P280 
P290 
P300 


P310 


P320 


P330 
P340 


P350 


P360 


Gross Pay summary cards and Income Tax Factor cards are separated. Income 
Tax Factor cards are filed. 


Gross Pay summary cards are sorted by Employee Number within Department. 
Last period Year-to-Date cards are merged with Gross Pay summary cards. 


Last period Year-to-Date cards, and Gross Pay summary cards are processed 
through the 407. A Control Register is printed. Current period Year-to-Date 
cards are punched by the 514 Summary Card Punch. 


Current period Year-to-Date cards are tabulated for totals on the 407. Totals are 
balanced to the Control Register produced by run P300. Current Year-to-Date 
cards are filed. 


Gross Pay summary cards and last period Year-to-Date summary cards are sorted 
apart. Last period Year-to-Date cards are filed. 


Gross Pay summary cards.are passed through the 407 to produce the Pay Register. 


The Master Name cards and Gross Pay summary cards are merged on the 085 
Collator. 


The combined Master Name cards and Gross Pay summary cards are processed 
through the 407 to prepare Pay Checks and current Earnings Statements. 


Master Name cards and Gross Pay summary cards are separated and filed. 


UNIVAC 9200 PAYROLL RUNS 


P10 


P20 


P30 


P40 


Time cards, previously punched, rated, and balanced to control, are sorted on the 
UNIVAC 2001 into Employee Number sequence within Department. 


The Univac 9200 with the Univac 1001 on-line processes Time cards in the U1001 
primary feed, combined Master Name and Deduction cards, and last period Earnings 
and Year-to-Date cards in the U1001 secondary feed. Blank cards are placed in 
the U9200 Card Punch Unit. Calculations are made to produce Gross Pay, Income 
Tax, Canada Pension Plan and Unemployment Insurance contribution amounts. 
Miscellaneous deductions are selected for the current pay period, the next pay 
amount is developed, and Year-to-Date data is updated. The Payroll Register is 
printed with department and overall totals for all current period amounts. New 
current period Earnings and Year-to-Date cards are punched. The U9200 has more 
than sufficient storage to hold the necessary program instructions, consequently, 
Unit Record runs P 1 2 0 through P 3 3 0 have been consolidated. 


The Univac 1001 is used to replace the previous Earnings and Year-to-Date cards 
in the payroll file with those for the current period. The previous Earnings and 
Year-to-Date cards are filed for later use in periodic reports. 


The second Univac 9200 run prints the Payroll Checks and Earnings Statements for 
the current period. Control totals are accumulated for balancing to the Payroll 
Register. 
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IV. PROGRAMMING 


INTRODUCTION 


All documentation and system design work done so far has been in preparation of the 

final application conversion task, Programming. Programming is the preparation of pro- 
grams, a series of related steps or instructions that tell the computer exactly how to handle 
a complete problem. The phases of programming are: 


Problem definition, using a Program Logic Chart or flowchart. 

Coding the problem in a form that the computer can use. 

Testing the completed program to determine if it will produce the desired results. 
Documenting the program for easy reference by all concerned. These phases are des- 
cribed in this chapter and techniques are suggested to make your programming effort 
easier. 


PROBLEM DEFINITION 


At the point of developing programs for the UNIVAC 9200 System, you will find that use 
of the present system documentation methods and forms (see Chapter II) has already 
enabled you to define the separate steps within most problems. This information may 
also have been updated during the application development phase (see Chapter III), by 
revising the forms. This documentation will, in most cases be enough to permit pro- 
gramming. The Multiple Card Layout form and Printer Format Chart are all that is needed 
to define input and output requirements. A review of the Program Logic charts will quick- 
ly establish whether they are adequate for determining calculations. 


Sometimes, however, the steps outlined in a series of Program Logic charts are difficult 
to follow, either because they are too numerous, or due to the complex interreactions of 
various sub-sections of the program. Whatever the reason may be, if any difficulties are 
experienced in determining calculations from the Program Logic Charts alone, the program 
should be promptly flowcharted for clear problem definition. 


Flowcharting Programs 


Program flowcharting differs from application flowcharting (completed during the docu- 
mentation phase of conversion see Chapter II) in that each computer run charted becomes 
a complete program. The Program Flowchart portrays all the logical steps involved in 
different processing procedures. Through its use, a program can be systematically 
visualized as a whole and its most complex portions can be readily analyzed. 


Five basic symbols, standardized throughout the data processing industry, are used in 
program flowcharting. They are as follows: 


1. Start symbol, used to indicate the beginning of a program or a distinct 


sub-routine of a program. 
Process symbol, indicates the arithmetic steps within the program. 


Decision symbol, shows these points in a program where a branch to alter- 
nate paths is possible, based on the occurrence of certain conditions. 


Connector, an entry from, or an exit to another part of the flowchart. 


End symbol, placed at the end of a program or a distinct sub-routine. 


Qo00Gy 
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In conjunction with these symbols, the following are used to ‘‘build’’ a flowchart. 


p ee epacmees 


=~ Arrows to indicate direction of data flow or the next step. 
2... = (Equal) 


# (Unequal) symbol used in conjunction with 
a decision to show conditions 
> (Greater) which cause a branch. 


< (Less) 


3: : Colon to indicate a comparison of two factors. 


The use of standard symbols in a complete flowchart is illustrated in Figure IV-2. This 
flowchart portrays Payroll operation P220 (shown in Chapter II, Figure II-12) which 
served to illustrate the use of the Program Logic Chart. Use of the flowchart may pro- 
vide further clarification of program logic prior to coding. 


On the flowchart, the symbol (_) containing the card type, indicates the processing that 
takes place for each card. The year-to-date Canada Pension Plan accumulation is 
subtracted from the yearly limit ($79.20). If the result is zero the limit has been reached 
and the Canada Pension Plan routine is bypassed. It should be noted that connections 


indicate entries to routine branches and re-entry to the ‘‘main chain’’ of coding. 


Flowcharting is a skill that requires practice to develop. The first attempt at drawing 
up a flowchart may be difficult. However, with practice, these initial mechanical diffi- 
culties will grow less and the program flow-chart will become a valuable tool with which 
to portray the total scope of the job and prepare it for coding. 


CODING 


Coding is that phase of programming in which a program, after having been flowcharted or 
otherwise defined, is translated into a form which a computer can handle. Coding informa- 
tion is divided into four categories: 


® Description of input 

@ Description of output 

@ Statements of calculations required 
@ Input and output devices to be used 


Univac has developed the Report Program Generator (RPG), a program generating 
language for any business application, as a tool for easier conversion of written problem 
definitions to computer language. RPG statements are prepared with the aid of special 
specification forms on which information concerning input, output, calculations and I/O 
units is written in a format acceptable to the UNIVAC 9200 System. The RPG is fully 
covered in the ‘‘UNIVAC 9200/9300 Card Report Program Generator Reference Manual,’’ 
UP-4106, which describes all RPG forms and specifications. 


The simple steps required for generation of a 9200 program, using the RPG, are indicated 
in the subsequent paragraphs which describe the writing of a program designated as the 
‘“‘worker program.’’ The steps are also portrayed in Figure IV-3. 


Step 1 Worker program information is recorded on the RPG specification forms. The data 
is written in a semi-English form known as source code. 
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Figure 1V-1. Program Logic Chart, Payroll operation P170. 
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Figure 1V-2. Flowchart, Payroll Operation P220. 
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Step 2 The source code specifications are then given to a keypunch operator who punches 
the worker program into specially designed RPG program input cards. 


ce 


Step 3 Since the source code definition of the problem is not the ‘‘official’’. language of: 
the computer, but rather a tool to make coding easier, these worker program Speci- 
fication cards are introduced to the RPG program previously stored in computer 
storage. The Generator program then translates the worker program source code 
into the true machine language instructions, commonly known as the object code. 


Step 4 The problem data can now be processed, using the object code worker program, to 
determine if the calculations made produce the desired output from the specified 
input. 


Program steps could be written in the object tode, thus eliminating the need for Step 3. 
This would, however, be far more difficult than:using the source code RPG language 
which allows a problem to be defined in everyday terms. It is a great deal simpler to let 
the RPG handle the ‘‘writing’’ of the program in machine language. 


The object code worker program generated by the RPG is available both in the main 
storage of the 9200 for immediate processing of the data defined by the worker program 
and also on punched cards to be used later to load the worker program into the computer. 
Each program loaded in storage destroys the program previously occupying that area. 
Having the object program on cards thus eliminates the use of the RPG to regenerate from 
source code whenever a worker program must be loaded and run. The RPG also provides a 
printed listing of the worker program on the UNIVAC 9200 printer. ‘This printout shows 
both the worker program source code and the object-code produced by the RPG and will 
indicate certain types of errors that may have been made in writing source code defini- 
tions. The RPG is fully described in the ‘‘SUNIVAC 9200/9300 Card Report Program 
Generator Reference Manual,’’ UP-4106, which covers all RPG forms and specifications. 


PROGRAM TESTING 


After a program has been coded, it must be tested to check that it will produce the desired 
results. Program testing involves three main functions: 


@ Desk-checking | 
w Preparation of test data 
w Program testing 


Desk-checking | 


Desk-checking is a very important phase of testing and one that should always be carried 
out. This procedure will save costly computer time when the program is actually tested. 
Desk-checking involves three functions: “ 


@ Review of program logic 
@ Validation of programming specification sheets 
@ Verification of program cards. 


Review of program logic. The logic of the program, as represented on a flowchart or a 
Program Logic Chart, must be checked against the specification forms to make certain 
that processing requirements are met. This insures that the program has basically been 
properly coded. 


Validation of program specification sheets. In this phase of desk-checking, the RPG 
specification sheets must be examined for coding errors such as: 
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Figure 1V-3. Report Program Generator production steps. 








@ Transposition of characters in labels 
@ Addition of characters in labels 

@ Omission of characters in labels 

w Use of undefined labels 

@ Labels off-punched one column 

Verification of program cards. The last phase of desk-checking is to verify the accuracy 
of cards keypunched from the RPG specification. This is done by comparing the specifi- 
cation sheets with: 


@ The program cards 
w A listing of the program cards 


Most of the errors on the cards are similar to those on the RPG sheets or consist of 
zeros and ones punched as alpha 0’s and I’s, or vice versa. 


Preparation of test data 
There are three ways to prepare data for program testing. They involve the use of: 


@ Existing data 
@ Specially prepared data ; 
@ A combination of existing and special data 


Test data should cover all branches of the program so as to insure comprehensive testing. 
It should, therefore, be prepared by the person who is best acquainted with the applica- 
tion. Even though he may not have any programming knowledge or even be on the EDP 
staff, he will be most aware of exceptions and conditions caused under special 
circumstances. 


After it has been prepared, test data should be thoroughly reviewed both by the person 

who prepared it and the programmer — to insure its accuracy and to check that it will 
provide a proper test of the program. The data should be keypunched, verified and listed. 
Control totals of the test data should be computed either manually or by a run on another 
machine. After the control totals have been computed, they should be checked for accuracy. 


Program Testing 


The purpose of machine-testing a program is to provide a final verification of prior desk- 
checking of the logic and computations of individual runs. To save costly computer time, 
all preparations for testing should be completed before going to the test location. The 
following information should be on hand: 


Program specification sheets 
Flowchart and/or Program Logic Chart 
Source code Program Card Deck 
Program test data 

Operator Instructions 


The programmer should thoroughly plan the testing session beforehand, establishing the 
exact testing sequence to be followed for each run, and indicating the purpose of each 
run and the expected results. Program testing is an important function for the success- 
ful completion of a program. A variety of program testing techniques can be used to 
arrive at the desired results. Some recommended procedures are listed below: 


1. A program should not be punched out from RPG regeneration until the RPG printout is 
completely error-free. 
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The logic of the program should be checked through the RPG printout. If the logic is - ; 
not correct, the RPG generation must be repeated. ee NH 


3. A small amount of test data should be used to test the program and produce a visual 
output. The validity of this output should then be checked. 


4. Test data with exceptions should be processed to check that they are handled properly. 
If the answers are not correct, the flowchart and/or the Program Logic Chart and the 
RPG printout should be used to determine the sequence of events which causes incor- 
rect results. 


5. Test data should be run to balance back to a control total computed before testing of 
the program. 


6. After the above procedures have been completed, the test data should be entered to test 
the program and insure that it is completely checked out. This test should insure that 
all aspects of the problem have been considered and resolved. 


After all pertinent programs have been checked out, the entire application can be tested. | 
The following procedures should be followed in testing an application: 


1. Each program must be tested until it produces the desired results. 


2. The interrelationship of programs as they will be processed for the application must 
be tested. For instance, the output from run A should be processed as the input of 
run B to follow the actual data flow of the application. 


3. A parallel test must be made to determine that a complete application is operational. 
This is done by processing the same data in the existing system and the new system, 
if possible. This parallel testing will pinpoint any oversights and will conclude a) 
testing of the application. 


DOCUMENTATION 


Proper program documentation is one of the most important factors in the success of any 
data processing installation. No organization, nor any department within it, can operate 
effectively unless it maintains proper and accurate records to prevent the many kinds of 
misunderstandings that can arise in the normal course of daily activities. ~~ 


The program documentation recommended for the UNIVAC 9200 is designed to contribute | 
greatly to the effectiveness of the day-to-day activity of the Data Processing Department. 
It can be prepared as a by-product of this activity with little or no additional effort by 
the program writer who designs or modifies a program and then includes the necessary 
information into one or both of the two main documentation sources: 


@ The Run Book . 
m The Application Book , 


The Run Book 


The Run Book is a collection of all required documentation pertaining to an individual 

program. Other information may also be included if it is necessary or if it makes it easier 

to understand the problem at hand and the approach chosen for its solution. The key to 

the effectiveness of the Run Book is that persons who are not associated with the creation 

of the program should experience no difficulties in referring to the Book and find its docu- 

mentation readily understandable. _ =e 





The Run Book contains several categories of information which should be filed in the 
same order that they are listed below: 


@ Run description 

= Input/output file specifications 
@ RPG specification forms 

@ RPG printout 

@ Operator instructions 


Each category of information may be one or more pages in length, as the program requires, 
and may also include additional illustrative and descriptive material. 


The Run Description. This is a descriptive document usually requiring only-a single page, 
which identifies a specific program and states its purpose. It indicates data file input, 
describes how it is to be handled by the program, and specifies the output to be produced. 
It also stipulates the frequency. with which the program is to be run. Each input and out- 
put file should be specifically identified by name and form number so that no errors may 
occur. 


The run description should also specify any related special considerations to be incorpor- 
ated into the program such as the three examples listed below: ; 


w If the sequence of input data is a prime consideration, the field sequence checked 
should be identified, and a statement of what is to be done with the ‘‘out-of-sequence”’ 
condition should be included. 

@ For data field(s) validation, the field(s) should be identified and the nature of the 
validation should be specified. The disposition of ‘‘invalid data’’ should also be 
specified. ; 

m@ If processing requires the presence of certain kinds of processing, a specification must 
be entered, such as: 


‘‘The first card of each STOCK NUMBER group must be a Stock Master; if not, the 
processing stops with notice of ‘missing master’ to the operator.”’ 


Input/ output file specifications. These include the Multiple Card Layout and Printer 
Layout forms prepared during the earlier stages of programming. Samples of actual input/ 
output cards and printer form samples may be included, if thought useful. These will be 
followed by the related Program Logic Forms. 


This section may also include a flowchart if one has been prepared to aid in filling out 
the Program Logic Forms. 


RPG specification forms. This category is comprised of the Report Program Generator 
forms prepared during programming. All are fully described in the ‘‘UNIVAC 9200/9300 
Card Report Program Generator Reference Manual,’’ UP-4106. It is suggested that the 

documents be listed in the following order: 


File Description Form 

Input Format Specification Form 
Calculation Specification Form 
Output Format Specification Form 
File Extension Specification Form 


RPG Printout. This follows the RPG specification forms and provides in printed form the 
complete detailed references for all preceding program specifications and the resulting 
object programs. 
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Operator Instructions. This final category of information in the Run Book includes a copy 
of the material written by the programmer to inform the operator of any variable conditions 
which will affect his handling of the program. The information includes the relationships 
of each input and output file to a specific peripheral device; and the enumeration of each 
Halt Condition handled by the programmer’s own coding, its indication to the operator, and 
what his response should be. 


In order to make the operator’s instructions easier to perform, many conditions have been 
standardized, (such as program load, start and termination, misfeed, output of paper, etc.) 
and do not have to be mentioned in the Run Book. 


The Application Book 


The Application Book is prepared when the functions within an application area are 
divided between two or more individual programs. Its purpose is to present information 
concerning the application area which was not included in the Run Books for the related 
program. This information includes a statement of the objectives to be fulfilled and a 
general description of the work to be accomplished within the area. 


The general description should be followed by a list of the specific programs within the 
application area, and a chart of the associated program series, using the Univac Applica- 
tion Chart form. The check lists for the individual programs should be included, as 
should any other supporting material which pertains to the area of application rather than 
solely to individual programs within it. 


The Application Book and the individual Run Books can be filed in one of two ways. 
Either they form separate individual files, or they are combined into individual sections. 
In the latter case, the Application Book is the first section, and the individual Run 
Books follow in the order specified on the list of programs provided as part of the 
Application Book. 


V. RECORD CONVERSION 


The UNIVAC 9200 installation procedures and the UNIVAC 9200 Report Program Gener- 
ator language are designed to permit the ready transfer of unit record applications to the 
computer, with no changes being required in the formats of existing data files. File con- 
version may, however, prove of great value after the 9200 has become fully operational. 
The method can then serve in subsequent systems design work to improve present appli- 
cations and develop new ones. Through it, the 9200 can be used to the limits of its pow- 
erful capabilities. The factors to beconsidered and the procedures to be followed for 
prompt and easy conversion of existing card files and creation of new files from manual 
records are outlined in this chapter. 


CONVERSION FACTORS 


Conversion of card files is usually a simple and well-defined task involving no more than 
relocating a number of fields and changing card controls or identifiers. Occasionally, ob- 
solete data must be eliminated or new, up-to-date information added. 


File conversion permits 9200 System users to conduct operations with clean, accurate 
files, free of any cards that require special handling, for which solid controls have been 
established. 


A major conversion effort may take several weeks to complete, and may involve several = 
separate conversion jobs. The user will therefore have to consider beforehand the major 

factors for the determination of conversion methods and timing. Only after the factors 

listed below have been examined and pertinent questions resolved can a successful con- 

version begin: 


m Need for additional equipment 
a File Volume 
mw File stability 


Need for Additional Equipment 


Temporary rental of additional equipment may be necessary for conversion, depending on 
the size of files to be converted and the conversion schedule. The need for more equip- 
ment may come up, for instance, if a large file must be converted over a single week-end. 
Inquiries should be made before conversion concerning local rental rates, delivery lead 
times, and minimum rental periods. 


File Volume 


Small, easily managed files can usually be converted as part of the regular work-flow. 
Larger, more complex files require special methods. One is to break the file down into 
manageable blocks. Most files have some numeric designation, such as department, pro- 
duct or customer records which will block the file records into fairly equal parts. Occa- 
sionally, an arbitrary breakdown, such as an alphabetic designation, must be used. A 
service bureau may be used to convert a large file within a short period of time without 
blocking. In any case, the need for close conversion control and supervision will increase 
in direct relation to the file size and complexity. It is also important that old and new 
files be clearly identified to prevent improper handling. 


File Stability 


The amount of updating or use to which a file is subjected will affect the timing of its 
conversion. 


69 

















70 


Master files are usually quite stable, even though used in a number of runs. Changes are 
simple: change of address, new credit limit, number of dependents and so forth. A file of 
this, type should be converted well in advance of the time that it is needed for cutover. 
Remember, however, that the creation of a second file means duplicate updating. If a new 
form has been designed to record the changes for keypunching, it should, if possible, be 
used with both the old and the new files. The early creation of new files provides 

greater scheduling flexibility and an opportunity to test new procedures and controls. 


Files, such as inventory or accounts receivable, that are continually subject to high 
volume changes can be converted just prior to their use in the new system, since early 
conversion would place an excessive burden on the staff. Careful planning is needed to 
schedule this job at the right moment. A business cycle cut-off point, such as month-end 
statements to customers, is the best time for conversion. A conservative schedule will, 
however, allow a time margin for a dress rehearsal of the operation and any required re- 
covery and rerun. 


CONVERSION PROCEDURES 
Conversion of the files can begin after the following necessary steps are scheduled: 


(1) The existing file should be audited and every effort made to clear it of extraneous 
data. The file must be complete and all records should be returned to it (if neces- 
sary, temporary copies of records can be made). Questionable records should be re- 
viewed by the proper personnel and decisions taken as to the proper content of these 
records. 


(2) Control totals are then tabulated and recorded by the control clerk. If the file has 
been divided into blocks, each segment will be treated as an independent unit. The 
control totals for statistical files can be simple and easy to maintain, but files that 
represent revenue, inventory or costs must be more strictly controlled. The major 
money or quantity field, as well as a hash total of identification numbers, should be 
established. The addition of a few more control fields will not reduce the throughput 
of a new system. 


(3) The cards are then reproduced by whichever method has been chosen. 


(4). Control totals for the new files should be developed, using the same fields as were 
used with the old files. The two sets of controls must balance before further pro- 
cessing can be undertaken. 


(5) The old files can now be returned to storage and the new records rearranged, if 
necessary. If the original total groups are disturbed by this manipulation, new con- 
trol totals must be established and checked out against the first set of controls. 


(6) If the new files have been created in advance of cutover, updating and maintenance 
must be done on a control basis. All input should be batched, totaled and recorded 
by the control clerk and the updated run totals verified. Any change in the old re- © 
cords must cause a corresponding change in the new records. 


(7) Thesame controls should be established if the new files have been created from 
manual records. The files should be keypunched and key verified in small batches 
for which adding machine tapes have been compiled. Extra care is needed here since 
manual files are usually spread throughout a department, and a longer period of audit 
and clean-up will be required. Tight control will have to be maintained on changes 
since non-machine oriented personnel seldom appreciate the recovery problems in- 
volved. Since control totals attest only to the accuracy of numeric fields totalled, it 
will be necessary to sight check the indicative information such as names, addresses, 





social insurance numbers, etc. The amount of sight checking will depend on the data. 
In some cases, the entire record will have to be checked. In others, merely reading 
the data will be sufficient, or spot checks may be all that is required. 


The new files can be used as soon as they have been created and proved to be satisfac- 
tory. The old files should not be discarded, however, until all wrinkles have been ironed 
out of the new system and it is self-sustaining. 


PLANNING THE FINAL CUTOVER 


A smooth and easy cutover to the new system will require answers to three major ques- 
tions — how applications are to be cutover, what physical controls can be exercised dur- 
ing cutover, andwhen this cutover is to take place. The determination which must be 
made for a successful cutover, therefore, are: , 


a Determination of the cutover method 
w Conversion controls 
m Conversion scheduling 


Determination of the Cutover Method 


Every application to be converted to the new system should be treated as a unit, with all 
associated runs peeing converted in the same time span. Three cutover approaches can be 
taken: 


@ Parallel, with both old and new equipment operating side-by-side until final debugging 
of the new system. 


a Immediate, with all old equipment being taken out immediately. 
@ Gradual, with new equipment being installed gradually. 


Parallel Conversion is recommended when the new system almost duplicates the old with 
essentially similar output. A satisfactory conversion can be accomplished in two produc- 
tion cycles. The old runs, which still produce usable information, are processed and a 
printout of all intermediate and final documentation is retained. The new runs are then 
processed, using the same input data, and the resulting documentation is compared with 
old-run output. Any discrepancies thus revealed are investigated by the system designer 
who makes suitable modifications to the program or procedures. Reruns are then made 
until the results check out. There will be instances where slight differences may be 
caused by changes in methods of calculation. A programmed payroll tax calculation, for 
instance, will yield results different from those obtained from a tax table. 


When the input of the first parallel run is acceptable, another parallel test will be made 
on the next production cycle. At least. one clean parallel cycle must be produced before 
the new system can be relied on to produce working output and the oldsystem terminated. 
This method is particularly recommended for detail-heavy accounting functions such as 
billing, payroll or inventory control. 


Immediate Conversion is used when input or output data bears little resemblance to that 
of the old system, or when the method of calculation to produce statistical output has 
changed. The task of modifying live input data and adjusting output from the old system 
to test the new prevents the adoption of the parallel approach. The old system is there- 
fore terminated and the new one is immediately cut in. 


Great care and planning are essential as the immediate conversion technique places the 
heaviest burden on the data processing staff. 
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The burden of developing appropriate volume tests before the conversion to ensure its ac- 
curacy falls almost entirely on the system designer. Testing should be sufficient to cover ed 
all possible suspected combinations of conditions. A change in operating procedures is 

usually associated with the immediate conversion method. Step-by-step instructions must 

be developed and tested and operating and clerical personnel adequately trained in their 

use. Keypunch operators should be thoroughly retrained when input content and format 

have changed. 


Gradual Conversion is implemented when the conversion job istoo big to handle within a 
limited period of time. Under this method, the total application can be divided into logical 
segments, each of which is cut over separately. This approach can be used only if the 
output of a new system segment is acceptable within the old system. The parallel method 
should be used in correcting each segment, since there must be a high degree of compati- 
bility between the two systems. 


If the application does not lend itself to segment-by-segment cutover, it must be divided 
in some other way, such as by department or customer number. This technique is similar 
to the blocking method for file conversion. Here, both systems must be run simultaneously, 
each producing a portion of the desired output. The people concerned should know that 
both old and new system output can be used, and a conversion schedule should be kept 
up-to-date. 


Although the gradual approach is necessary in certain cases, it is quite difficult to con- 
trol, and very careful supervision is needed. 


Conversion Controls 


Controls for application conversion consist of operation check points and balancing fig- 
ures developed outside the computer room. Controls used during conversion must be ac- NA 
companied by specific recovery techniques. 


Operation Check Points occur at the stopping places found in any system where completed 
work can be inspected for accuracy. In a payroll run, for instance, a visual check of the 
gross-to-net calculation will reveal any amounts outside a predetermined range. A correc- 
tion at this stage, before any checks are printed, will save unnecessary work later. Some 
check points will have been built into the system by the designer, for example, the credit 
limit check in a billing run. Some control totals are developed in the first run of a system 
and are checked at every subsequent input and output operation. These totals are solely 
for computer room use and may take the form of hash totals to verify that every record re- 
ceived has been processed. Whatever the check may be, it is designed to prevent an error 
from being compounded and causing excessive remns, 


Accounting Controls represent the majority of checks normally used by an EDP department. 
Timekeeper reports are batched, accounts receivable checks are totaled, production fig: 
ures are verified, general ledger vouchers are keypunched, and so forth. All but statistical 
reports can usually be balanced back to some control established by the accounting de- 
partment. The necessary controls are incorporated into the program by the systems de- 
signer. The EDP department is responsible for verifying the accuracy of each report before 
it is released. 


Recovery Techniques are the procedures used to correct the errors which the controls re- 
veal. Recovery techniques used during the installation period may differ from those used 
for normal system operations. The parallel method of conversion provides a complete 
check on every run, and recovery means continuous adjustment and rerunning until old and 
new outputs balance out. The immediate method of conversion differs in that normal ope- 
rating conditions occur right away. If normal recovery techniques fail, the old system can 





be put back into operation with only minor consequences, but this is a last resort and 
should be avoided. The gradual method of conversion presents a more complex problem 
as normal recovery is used for the portion of the run still under the old system, but new 
recovery techniques are used for the new system. Any errors in one system must be ana- 
lyzed to discover what effects they may have on the other systems. 


Recovery procedures should be simple enough so that only the affected portion of the run 

needs to be done over, if possible. An example would be the discovery, after running a 4 
large payroll register, that errors were made in the third and sixth of 25 departments. Only 

the rerunning of these two departments and manual correction of overall run totals should 

be required. Large jobs should thus be subdivided to permit simple recovery. 


Special steps should be taken for those runs where an updated file is produced. The old 

file should be held for two cycles to facilitate its reconstruction if anything happens to 

the new files. If possible, the input records that caused the changes should be kept in > 
their original sequence. 


Conversion Scheduling 


Cutover to the new system should be based on a firm schedule to be drawn up as early as 
possible. This schedule should show in detail: exactly what must be done — the sequence 
in which it must be done — and the starting and completion dates for each scheduled con- 
version activity. It is very important that it be completely realistic, fully reflecting the 
extent of the conversion job and the speed with which you can accomplish it. 


The successful development of a realistic conversion schedule is based on four major 
considerations: 


a Conversion tasks to be done 

a The time at which they should be done 
a The resulting preliminary schedule 

a Firming the conversion schedule 


Conversion tasks to be done 


All operations to be converted should be identified before any kind of conversion sche- 
dule can be drawn up. For this purpose, the following steps should be taken to prepare-a 
detailed list of operations. 


(1) List every application to be converted. 
(2) Breakdown each application into individual runs. 
(3) List all runs in proper sequence. 


(4) Indicate for each run whether it is performed on a daily, weekly, monthly or other 
periodic basis. 


(5) Use special symbols to indicate: 


— one-time conversion runs. 
— runs that are related to each other. 


(6) List operations or processing runs that do not relate to any one application. 


After you have completed the list, you should review it thoroughly to make certain that it 
is complete and without duplications. 
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Conversion timing N 


It is important to know when each application can be cut over to the new system so as to 
assign it a conversion priority. Conversion must always take place at the start of the pro- 
cessing cycle — either of the entire application or of the next segment to be converted if 
a very large file has had to be broken down into manageable blocks. Equipment limita- 
tions or management decisions may, however, affect the time at which actual processing 
can begin. 


Once the conversion sequence is known, the list of operations to be converted should be 
reatranged to conform with that order. The list should be carefully checked afterwards to 
make certain that input/output continuity between runs is preserved. If conversion of a 
given application must be stretched out, temporary processing measures must be taken to 
preserve continuity between runs. 


The preliminary conversion schedule 


After all runs have been itemized and each application has been assigned a_ priority for. 


‘conversion, the creation of the preliminary conversion schedule can begin. The first step 


is to determine the time required for each conversion task — to convert a given file or to 
complete a certain operation. These time estimates can be made more accurate by check- 
ing some testing times for new system runs. 


Once that conversion times for each run have been determined, this information is trans- 

ferred in conversion sequence to a chart or progress board. Applications should be shown 
across the bottom of either the chart or the board and the sides should be ealibrated ver- 

tically in time units. This procedure will permit easy visualization of the whole. schedule 
and of each element within it. 


Firming the conversion schedule 


Before the preliminary schedule can be firmed, you must make certain that it is realistic. 
If it is not, the schedule must be redrawn or additional support acquired. The factors to 
be considered include: 


a Current workload. Is it too great to permit conversion during the time specified in the 
schedule? 


a Personnel. Is staff training satisfactory? Is the staff adequate to support both the cur- 
rent workload and the conversion effort? If it is not, should temporary personnel be 
hired? 


m Equipment. Is existing equipment adequate for conversion of files within the schedule? 
If it is not, should additional equipment be rented temporarily? 


a Miscellaneous. Have adequate provisions been made for additional storage and working 
space, furniture and operating supplies that may be required? 


ws The new system. When is the new equipment to be delivered, and according to what 
schedule? What is the progress of site preparation? 


Answers to these questions will indicate whether the preliminary ‘‘ideal’’ schedule can 
be kept or whether it must be modified to fit existing conditions. Once the schedule has 
been firmed, however, every effort must be made to stick with it. 
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